PEP 668（Marking Python Packages as Externally Managed）是 Python 官方在 Python 3.11 提出的更新，解決了 Linux 發行版系統套件（如 apt、pacman）與 Python 官方套件庫 pip 之間的衝突矛盾。

如果你近期在 Ubuntu 23.04+、Debian 12+ 或 Arch Linux 上執行 sudo pip install <package>，很有可能會遇到以下經典的紅色錯誤訊息：

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

這個error是 PEP 668 正式生效 所觸發的保護機制。

為什麼需要 PEP 668？

在 PEP 668 之前，Python 開發者常使用 sudo pip install 將套件直接安裝到系統層級的 Python 目錄下（例如 /usr/lib/python3.x/site-packages/）。這種做法會帶來嚴重的系統隱患：

• 檔案覆蓋風險：Linux 發行版的套件管理器（如 apt）本身也依賴 Python 套件。若用 pip 強行更新了系統套件所依賴的底層函式庫，容易導致系統工具直接崩潰。
• 相依性破壞：apt 無法追蹤 pip 手動安裝或修改的檔案，造成套件狀態不一致（Dependency Hell）。
• 清理困難：過一段時間後，無法辨識 /usr/local/lib/ 裡的套件究竟是系統安裝的，還是開發者手動輸入 pip 安裝的遺留物。

PEP 668 的運作原理

發行版維護者可以在系統 Python 環境的 site-packages 目錄中，放置一個名為 EXTERNALLY-MANAGED 的標記檔案。

當 pip 嘗試在此環境下執行安裝或更新指令時，會先檢查該檔案是否存在：

/usr/lib/python3.x/site-packages/EXTERNALLY-MANAGED

若檔案存在，pip 會立即中斷執行，並印出該檔案內預先撰寫好的提示文字，指導使用者改用標準且安全的方式管理套件。

解決方案與最佳實踐

面對 PEP 668 限制，開發者應根據使用情境選擇適當的解決方案。

1. 使用虛擬環境（官方推薦最佳解）

使用 Python 內建的 venv 模組建立隔離環境。虛擬環境內部不會遺傳系統層級的 EXTERNALLY-MANAGED 檔案，因此可以自由使用 pip。

python3 -m venv myenv

source myenv/bin/activate

pip install requests

2. 使用 pipx 安裝獨立 CLI 工具

如果你只是想安裝某個 Python 寫成的命令列工具（例如 black、yt-dlp、ansible），不需要手動建立 venv，可以使用 pipx。pipx 會自動為每個工具建立獨立的虛擬環境，並將可執行檔連結至系統 PATH 中。

sudo apt install pipx
pipx ensurepath

pipx install yt-dlp

3. 強制繞過限制（不推薦，警示）

如果確有特殊需求（如 Docker 容器化建置環境），可以使用 --break-system-packages 旗標繞過 PEP 668 的限制。

⚠️ 警告：此操作可能導致 Linux 系統內建的 Python 工具破壞或失效，請謹慎使用。

pip install requests --break-system-packages

PEP 668 並不是阻礙開發者，而是給予 Python 生態系明確的分工：「系統的歸系統，開發的歸虛擬環境」。理解這一點後，建立良好的 Python 虛擬環境習慣將能有效節省未來的維護成本。